Context

Split off from #712. voice.Decode trusted the packet-length header over the datagram: it read packetLength from the first two bytes and then worked backwards from that offset without ever checking that the offset was consistent with the actual datagram or with the declared segment lengths.

A corrupt or truncated packet whose header still happened to point within bounds could decode into a plausible-looking Packet with a garbage OriginGUID. A receiver consuming that packet would treat it as a real transmitter capable of holding a frequency.

Change

Decode now rejects a packet if:

• the length header doesn't match the actual datagram length
• the header + audio + frequencies + fixed segment lengths don't sum to the declared packet length
• the frequencies segment length isn't a whole multiple of a single frequency's encoded length

Verified against a live server

Cross-checked the new validation against a packet captured on eu.limakilo.net (receive only, never transmitted) carrying four frequencies: header 6 + audio 31 + frequencies 40 + fixed 58 = 135 bytes, matching the datagram size. TestDecodeMatchesObservedFraming pins this.

Testing

make test && make lint vet fix format && go mod tidy   # all pass, no further changes

New tests: round-trip encode/decode across single/multiple/encrypted/no-audio frequency sets, the observed-framing regression above, and rejection of truncated datagrams, mismatched length headers, and inconsistent segment lengths.

🤖 Generated with Claude Code